Related:

• Change default Wide width alignment for Media & Text block to normal width. #20941
• Media & Text: Switch default alignment to none #48404

What?

Provides additional data from which deprecations can check if they are eligible.

Why?

The information currently passed to the isEligible check is insufficient in some cases to determine if a deprecation should in fact run.

One use case requiring additional information can be found in:

• Media & Text: Switch default alignment to none #48404

In the above example, when the default align attribute has its default switched to none, existing blocks using the default wide align are not determined to be invalid. This is due to the custom CSS class name support picking up the deprecated alignwide class from the markup and adding it to the className attribute.

As the deprecated block is still determined to be valid, the deprecation's isEligible callback must be able to return true in this scenario. The catch is presently the isEligible function is passed only the raw parsed attributes and inner blocks. The raw parsed attributes do not yet have any amendments made to the className attribute by the custom class names support.

How?

• Passes a third param to a deprecation's isEligible function. That being and object now including the current block e.g. { block }.
• An object was chosen as it could more easily be extended if there is a need for access to the raw markup, raw block etc.
• No changes are required to existing isEligible function definitions.

Alternative Approaches

Pass only rawBlock and current block as extra params

This would avoid the creation of a new object and potential minimise any performance hit. It would make for a rather awkward signature and API.

isEligibleV2

This approach would allow deprecations to define their eligibility check via a new function signature.
e.g. isEligibleV2( rawBlock, currentBlock ).

This would still provide the existing data via rawBlock.attributes and currentBlock.innerBlocks but also allow checks to be made against the markup or finalized block attributes.

Some downsides are the multiple function signatures, the potential need to deprecate one eventually, potential confusion etc. The upside is primarily the clean function signature and only passing the extra data when a deprecation desires it.

Adding a disallow list to Custom CSS Classname support

This is a more heavy-handed and hacky approach with a greater potential performance hit.

Blocks could define a disallow list for custom class names. That list can be checked during the determination of custom class names from the block's markup. A CSS class is only added to the className attribute if it wasn't in the disallow list.

Using the media and text example, alignwide could be disallowed, which would then cause unmigrated blocks to be invalidated triggering the necessary deprecation without the need for the isEligible check.

Testing Instructions

1. Ensure block fixture tests still pass: npm run test:unit test/integration/full-content/full-content.test.js
2. Proofread block deprecation docs update
3. Test Media & Text: Switch default alignment to none #48404 which is now based on this PR